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1. Real Party in Interest 

The real party in interest is Waterleaf Limited, the assignee of record. 

II. Related Appeals and Interferences 

Applicant is not aware of any related appeals or interferences. 

III. Status of Claims 

Claims 26-40 are pending and stand rejected. Claims 1-25 have been canceled. 
The rejection of claim 26-40 is being appealed. A clean set of the pending claims is 
attached in the Claims Appendix beginning at page 13. 

IV. Status of Amendments 

No amendments were filed after the final rejection mailed November 24, 2008. 

V. Summary of Claimed Subject Matter 

Of the claims being appealed, claims 26 and 34 are independent. Claims 27-33 
are dependent on claim 26. Claims 35-40 are dependent on claim 34. 

Claim 26 is directed to a gaming system, comprising: (a) at least one player 
station for displaying to a player a simulation of a game of chance (see Specification, p. 

2, lines 21-23; p. 6, lines 10-12; p. 6, lines 14-18; p. 6, lines 22-27; p. 7, lines 3-6; and p. 
8, lines 20-24); (b) a primary gaming server located remotely from the at least one player 
station and communicable with the at least one player station via a communication 
network, wherein the primary gaming server is configured to provide outcomes for the 
game of chance upon request from the at least one player station (see Specification, p. 2, 
lines 24-28; p. 3, lines 19-23; p. 6, lines 10-14; p. 7, lines 1-3; p. 7, lines 16-18; and p. 8, 
lines 1-7); (c) a secondary gaming server located remotely from the at least one player 
station and communicable with the at least one player station via the communication 
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network, wherein the secondary gaming server is configured to provide outcomes for the 
game of chance upon request from the at least one player station (see Specification, p. 2, 
line 29 - p. 3, line 2; p. 3, lines 19-23; p. 6, lines 10-14; p. 7, lines 1-3; p. 7, lines 16-18; 
and p. 8, lines 9-16); (d) a watchdog facility configured to (i) transmit a data packet to the 
primary gaming server at regular intervals and (ii) whenever an expected response is not 
received from the primary gaming server within a predetermined time interval, to change 
a status of the primary gaming server from active to failed (see Specification, p. 3, lines 
23 - p. 4, line 1; p. 4, lines 6-8; p. 7, lines 7-10; and p. 8, line 26 - p. 9, line 5); and (e) a 
controller in the at least one player station for routing a request to provide an outcome of 
a turn of the game of chance, wherein the controller routes the request to the primary 
gaming server when the status of the primary gaming server is active and routes the 
request to the secondary gaming server when the status of the primary gaming server is 
failed (see Specification, p. 7, lines 7-10; and p. 8, lines 1-16). 

Claim 34 is directed to a method of operating a gaming system, the gaming 
system comprising a player station, a primary gaming server, and a secondary gaming 
server, the player station being remotely located from and communicable with the 
primary and secondary gaming servers via a communication network. The method 
comprises the steps of: (a) displaying on the player station a simulation of a game of 
chance (see Specification, p. 4, lines 16-18; p. 6, lines 14-18; p. 6, lines 22-23; and p. 7, 
lines 3-6); (b) a watchdog facility transmitting a data packet to the primary gaming server 
at regular intervals (see Specification, p. 5, lines 7-11; and p. 8, line 26 - p. 9, line 2); (c) 
the watchdog facility changing a status of the primary gaming server from active to failed 
whenever an expected response to the data packet is not received from the primary 
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gaming server within a predetermined time interval (see Specification, p. 5, lines 12-15; 
and p. 9, lines 2-5); (d) a controller in the player station routing a request to provide an 
outcome of a turn of the game of chance, wherein the controller routes request to the 
primary gaming server when the status of the primary server is active and routes the 
request to the secondary gaming server when the status of the primary gaming server is 
failed (see Specification, p. 7, lines 7-10; and p. 8, lines 1-16); (e) determining an 
outcome in response to the request (see Specification, p. 8, lines 1-16); and (f) the player 
station receiving the outcome via the communication network and displaying the 
outcome to a player (see Specification, p. 8, lines 1 8-24). 

VI. Grounds of Rejection to be Reviewed on Appeal 

Claims 26-32 and 34-39 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Coile et al., U.S. Patent No. 6,108,300 ("Coile") in view of Holch et 
al., U.S. Patent No. 5,674,128 ("Holch"). Claims 33 and 40 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over Coile in view of Holch, and further in view of 
Duncombe et al., U.S. Pub. No. 2003/0120685 ("Duncombe"). 

VII. Argument 

A. The Examiner Erred in Rejecting Claims 26-32 and 34-39 Under 35 
U.S.C. § 103(a) as Being Unpatentable Over Coile in View of Holch 

Independent claims 26 and 34 are directed, respectively, to a gaming system and a 

method of operating a gaming system, in which a watchdog facility determines whether 

the status of a primary gaming server is "active" or "failed" and a controller in a player 

station routes a request to provide an outcome of a turn of the game based on this status, 

routing the request to the primary gaming server when the status is "active" and routing 

the request to a secondary gaming server when the status is "failed." In this regard, claim 
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26 recites "a watchdog facility configured to (i) transmit a data packet to the primary 
gaming server at regular intervals and (ii) whenever an expected response is not received 
from the primary gaming server within a predetermined time interval, to change a status 
of the primary gaming server from active to failed" and "a controller in the at least one 
player station for routing a request to provide an outcome of a turn of a game of chance, 
wherein the controller routes the request to the primary gaming server when the status of 
the primary gaming server is active and routes the request to the secondary gaming server 
when the status of the primary gaming server is failed." Claim 34 includes similar 
language. 

In rejecting claims 26 and 34, the Examiner argued that Coile discloses both the 
claimed "watchdog facility" and the claimed "controller." See Final Office Action, pp. 2- 
3. But the Examiner's rejections are fatally flawed for at least two reasons. First, the 
Examiner has used an improper "mix-and-match" approach by relying on some features 
of one system in Coile (Figure 1, including client 100) and relying on other features of a 
completely contrary system in Coile (Figure 2, including client 200), as if these two, 
contrary systems were one and the same system. Second, Coile does not disclose a 
watchdog facility that detects when an expected response is not received from the 
primary server within a predetermined time interval. These two points are discussed in 
detail below. 

1. The Examiner has used an improper "mix-and-match" 
approach 

In an obviousness rejection, "[o]ne cannot use hindsight reconstruction to pick 
and choose among isolated disclosures in the prior art to deprecate the claimed 
invention." In re Fine, 837 F.2d 1071, 1075 (Fed. Cir. 1988). And it is impermissible 
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"to pick and choose from any one reference only so much of it as will support a given 
position, to the exclusion of other parts necessary to the full appreciation of what such 
reference fairly suggests to one of ordinary skill in the art." In re Wesslau, 353 F.2d 238, 
241 (CCPA 1965). The Examiner, however, has done just that by relying on some 
features of one system disclosed in Coile (Figure 1, including client 100) and relying on 
other features of a completely contrary system disclosed in Coile (Figure 2, including 
client 200), as if these two, contrary systems were one and the same system. 

Figure 1 is described in the "Background" section of Coile as illustrating "a 
typical backup system." See col. 2, lines 29-30. The Figure 1 system includes a client 
100, a primary network device 110, and a backup network device 120, See col. 2, lines 
30-49. The Figure 1 system requires client 100 to sense when primary network device 
110 fails and requires client 100 to switch its connection to backup network device 120 
when primary network device 110 fails. See col. 2, lines 50-52, lines 56-58, and lines 63- 
65. To achieve this functionality, client 100 stores the IP address and MAC address of 
primary network device 1 10 in register 102 and stores the IP address and MAC addresses 
of backup network device 120 in register 104. See col. 2, lines 52-54 and 58-60. This is 
illustrated in Figure 1, which is reproduced below: 




120 
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As a result, client 100 is able to change the addresses in the relevant packet headers so 
that packets are sent to the backup network device when the primary network device 
fails. See col. 2, lines 60-63 and col. 2, line 65 - col. 3, line 2. 

Figure 2 is described in the "Detailed Description" section of Coile as illustrating 
"a fail over system designed according to the present invention." See col. 5, lines 14-15. 
The Figure 2 system includes a client 200, a primary server 210, and a backup server 220. 
See col. 5, lines 1 5-42. Client 200 stores the target IP address for the connection which 
the client wishes to make, but client 200 does not store the active and standby IP and 
MAC addresses for the primary and backup servers. See col. 5, lines 15-19. Instead, 
when primary server 210 is in the active state (i.e., has not failed), it will respond to any 
packets sent to the active IP or MAC address. See col. 5, lines 55-58. If the primary 
server fails, the backup server becomes active and assumes the active IP address and 
active MAC address. See col. 7, lines 5-15. Figure 2 is reproduced below: 
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Thus, in the Figure 1 system, client 100 determines whether to route packets to 
the primary device or to the backup device (by sensing whether the primary device is 
active or failed) and includes the appropriate addresses for the primary or backup device 
in the packet headers. In contrast, client 200 in the Figure 2 system does not determine 



whether to route packets to the primary server or to the backup server. This is because 
the backup server, rather than client 200, determines when the primary server fails. 
Moreover, the backup server automatically assumes the active IP and MAC addresses 
when the primary server fails, so that client 200 does not need to determine which server 
should receive the packets. Indeed, client 200 does not even store the addresses of the 
primary and backup servers. Thus, the systems in Figures 1 and 2 are completely 
contrary implementations. 

Unfortunately, in rejecting claims 26 and 24, the Examiner has mixed together 
different features from these two, contrary systems. For the "player station" recited in 
claims 26 and 34, the Examiner cited client 200 in Figure 2. See Final Office Action, p. 

2. But for the "controller" in the player station, the Examiner cited col. 2, line 50 - col. 

3, line 2, a section that describes client 100 in Figure 1. See Final Office Action, p. 3. 
According to the Examiner, "the controller routes the request to the primary server when 
the status of the primary server is active (i.e. with the use of the primary MAC and IP 
address) and routes the request to the secondary or backup server when the status of the 
primary server is failed (i.e., with the use of the backup MAC and IP address). Id, Thus, 
the Examiner's rationale requires the "player station" (client 200, which does not store 
the active and standby IP and MAC addresses for the primary and backup server) to 
include a "controller" that does require the primary and backup MAC and IP addresses in 
order to route requests to either the primary or backup server. 

The Examiner's rationale must be rejected as being self-contradictory. The player 
station cannot both not store primary and backup addresses (as in client 200) and store 
primary and backup addresses (as in client 100). At the very least, the Examiner has 
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provided no reason why a person of ordinary skill in the art would have modified client 
200 in Coile to incorporate the routing function of client 100. To the contrary, since the 
servers in the Figure 2 system automatically receive the appropriate addresses, there 
would be no reason to modify client 200 so that it addresses packets to reach either the 
primary or backup server. Moreover, Coile' s statement that "[c]lient 200 does not store 
the active and standby IP and MAC addresses for a primary and backup server" (col. 5, 
lines 17-19) teaches away from any such modification of client 200. For this reason 
alone, the Examiner's rejection of claims 26-32 and 34-39 is clearly erroneous and should 
be reversed. 

But the Examiner's improper and "mix-and-match" approach does not end there. 
The Examiner's rationale for finding a "watchdog facility" in Coile also mixes together 
features from the Figure 1 system and the Figure 2 system. In particular, the Examiner 
argued that Coile discloses "a watchdog facility or an application configures the primary 
server to receive data packet at regular intervals," citing to col. 5, lines 19-25. See Final 
Office Action, p. 2. That section refers to the Figure 2 system. The Examiner also 
argued that the data packets were "transmitted by a client," citing to col. 2, line 65 - col. 
3, lines 2. That section refers to the Figure 1 system. Thus, it is not clear whether the 
Examiner regards the claimed "watchdog facility" to be part of the Figure 1 system, part 
of the Figure 2 system, or part of some hypothetical combination of the Figure 1 and 
Figure 2 systems. Applicant hopes that the Examiner will clarify this point, in case the 
Examiner continues to pursue these claim rejections. 

By relying on some features of the Figure 1 system in Coile and on some features 
of the contrary Figure 2 system in Coile, the Examiner's rationale for rejecting claims 26- 

8 



32 and 34-39 lacks internal consistency and is fatally flawed. Accordingly, Applicant 
submits that the Examiner's rejection of claims 26-32 and 34-39 is clearly erroneous and 
should be reversed. 

2. Coile does not disclose the claimed "watchdog facility" 

Claim 26 recites "a watchdog facility configured to (i) transmit a data packet to 
the primary gaming server at regular intervals and (ii) whenever an expected response is 
not received from the primary gaming server within a predetermined time interval, to 
change a status of the primary gaming server from active to failed." Similarly, claim 34 
recites "a watchdog facility transmitting a data packet to the primary gaming server at 
regular intervals" and "the watchdog facility changing a status of the primary gaming 
server from active to failed whenever an expected response to the data packet is not 
received from the primary gaming server within a predetermined period of time." 

In rejecting claims 26 and 34, the Examiner argued that Coile discloses the 

claimed "watchdog facility." See Final Office Action, pp. 2-3. In the Examiner's 

rationale, the "data packet" transmitted at regular intervals is transmitted by a client, 

specifically client 100 described in col. 2, line 65 - col. 3, line 2. For the function of 

determining when an "expected response" to the data packet is not received from the 

primary gaming server within a predetermined time interval, the Examiner cited to Figure 

5 and a section of Coile describing Figure 5 (col. 9, lines 61-65). In this regard, Coile 

discloses a process that determines whether an "expected message" is received: 

FIG. 5 is a process flow diagram illustrating the process for failing one of 
the network devices when an expected confirmation message is not 
received on the network. . . . When an expected message is not received 
within an expected time frame, then control is transferred to a step 520 and 
the network device continues to listen for the next confirmation message. 
If that message is received, then control is transferred to step 510 and the 
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remote network device is not failed. If the message is not received within 
the expected time, then control is transferred to a step 530 and the local 
network device which did not receive the expected message enters test 
mode. 

See col. 9, line 62 - col. 10, line 3. 

The flaw in the Examiner's rationale is that the "expected message" in Coile is 

not an "expected response" to a data packet, much less a data packet transmitted by client 

100. As set forth in the passage quoted above, the "expected message" is an "expected 

confirmation message." The "confirmation messages" are messages that the primary and 

secondary servers send to each other periodically to confirm that they have not failed: 

Primary server 210 and backup server 220 periodically confirm to each 
other that they have not failed. In one embodiment, the primary network 
device and the secondary network device communicate every 15 seconds 
on the network, each sending a message to the other indicating that it has 
not failed. If one of the devices fails to receive a confirmation message 
within the prescribed interval, then the network device transfers to a test 
mode where it tests whether or not its network card is functioning. 

See col. 6, lines 14-22. In addition to sending confirmation messages across the network, 

the primary and secondary network devices also send confirmation messages to each 

other periodically via a failover cable. See col. 6, lines 37-40. Thus, in Coile's approach, 

the servers send each other confirmation messages periodically (e.g., every 15 seconds), 

not in response to data packets. The "expected messages" or "confirmation messages" in 

Coile are not expected responses to data packets, and they are certainly not responses to 

data packets sent by client 100. 

Accordingly, Coile teaches a fundamentally different approach than the 

"watchdog facility" recited in claims 26 and 34. Coile's process for determining active 

or failed status relies on one-way communication (receiving an expected message within 

an expected period of time). In contrast, the claimed "watchdog facility" uses two-way 
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communication (transmitting a data packet and waiting for a response within a 
predetermined period of time) for determining whether to change the status of the 
primary gaming server from active to failed. 

Based on the foregoing, Applicant submits that Coile neither discloses nor 
suggests either "a watchdog facility configured to . . . (ii) whenever an expected response 
is not received from the primary gaming server within a predetermined time interval, to 
change a status of the primary gaming server from active to failed," as recited in claim 
26, or "the watchdog facility changing a status of the primary gaming server from active 
to failed whenever an expected response to the data packet is not received from the 
primary gaming server within a predetermined period of time," as recited in claim 34. 
Applicant further submits that Holch does not make up for this deficiency in Coile. 

Because Coile in view of Holch does not teach a "watchdog facility" as recited in 

claims 26 and 34, Applicant submits that the Examiner's rejection of 26-32 and 34-39 is 

clearly erroneous and should be reversed. 

B. The Examiner Erred in Rejecting Claims 33 and 40 Under 35 U.S.C. § 
103(a) as Being Unpatentable Over Coile in View of Holch, and 
Further in View of Buncombe 

Claim 33 is dependent on claim 26, and claim 40 is dependent on claim 34. 

Applicant submits that the rejections of claims 33 and 40 are erroneous for at least the 

same reasons as set forth above for claims 26-32 and 34-39. Moreover, if an independent 

claim is nonobvious, then any claim depending therefrom is nonobvious. In re Fine, 837 

F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). 
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C. Conclusion 

Applicant has demonstrated that the rejections of claims 26-40 are erroneous as a 
matter of law. Applicant therefore requests reversal of the rejections and allowance of all 
pending claims in this application. 

Respectfully submitted, 
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Date; April 22, 2009 By: 

Richard A. Machonkin 
Reg. No. 41,962 
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VIII. Claims Appendix 



Claims 1-25: Canceled 

26. (previously presented) A gaming system comprising: 

at least one player station for displaying to a player a simulation of a game of 

chance; 

a primary gaming server located remotely from the at least one player station and 
communicable with the at least one player station via a communication network, wherein 
the primary gaming server is configured to provide outcomes for the game of chance 
upon request from the at least one player station; 

a secondary gaming server located remotely from the at least one player station 
and communicable with the at least one player station via the communication network, 
wherein the secondary gaming server is configured to provide outcomes for the game of 
chance upon request from the at least one player station; 

a watchdog facility configured (i) to transmit a data packet to the primary gaming 
server at regular intervals and (ii) whenever an expected response is not received from the 
primary gaming server within a predetermined time interval, to change a status of the 
primary gaming server from active to failed; and 

a controller in the at least one player station for routing a request to provide an 
outcome of a turn of the game of chance, wherein the controller routes the request to the 
primary gaming server when the status of the primary gaming server is active and routes 



13 



the request to the secondary gaming server when the status of the primary gaming server 
is failed. 

27. (previously presented) A gaming system as claimed in claim 26, wherein the 
primary gaming server uses a primary random number generator to determine outcomes 
for the game of chance and the secondary gaming server uses a secondary random 
number generator to determine outcomes for the game of chance. 

28. (previously presented) A gaming system as claimed in claim 27, wherein the 
primary and secondary random number generators are software random number 
generators. 

29. (previously presented) A gaming system as claimed in claim 26, wherein the 
at least one player station is a computer workstation and the communication network is 
the Internet. 

30. (previously presented) A gaming system as claimed in claim 26, wherein the 
watchdog facility is a program executed on the at least one player station. 

31. (previously presented) A gaming system as claimed in claim 30, wherein the 
watchdog facility generates an alarm when the status of the primary gaming server 
changes from active to failed. 
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32. (previously presented) A gaming system as claimed in claim 31, wherein the 
alarm is audible and/or visible. 

33. (previously presented) A gaming system as claimed in claim 26, wherein the 
primary and secondary gaming servers synchronize their data at regular intervals. 

34. (previously presented) A method of operating a gaming system, the gaming 
system comprising a player station, a primary gaming server, and a secondary gaming 
server, the player station being remotely located from and communicable with the 
primary and secondary gaming servers via a communication network, the method 
comprising the steps of: 

displaying on the player station a simulation of a game of chance; 
a watchdog facility transmitting a data packet to the primary gaming server at 
regular intervals; 

the watchdog facility changing a status of the primary gaming server from active 
to failed whenever an expected response to the data packet is not received from the 
primary gaming server within a predetermined time interval; 

a controller in the player station routing a request to provide an outcome of a turn 
of the game of chance, wherein the controller routes request to the primary gaming server 
when the status of the primary gaming server is active and routes the request to the 
secondary gaming server when the status of the primary gaming server is failed; 

determining an outcome in response to the request; and 
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the player station receiving the outcome via the communication network and 
displaying the outcome to a player. 

35. (previously presented) A method as claimed in claim 34, wherein 
determining an outcome in response to the request comprises: 

the primary gaming server executing a primary random number generator. 

36. (previously presented) A method as claimed in claim 34, wherein 
determining an outcome in response to the request comprises: 

the secondary gaming server executing a secondary random number generator. 

37. (previously presented) A method as claimed in claim 34, further comprising: 
executing the watchdog facility on the player station. 

38. (previously presented) A method as claimed in claim 37, further comprising: 
the watchdog facility generating an alarm when the status of the primary gaming 

server changes from active to failed. 

39. (previously presented) A method as claimed in claim 38, wherein the alarm 
is audible and/or visible. 
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40. (previously presented) A method as claimed in claim 34, further comprising: 
the primary and secondary gaming servers synchronizing their data at regular 
intervals. 
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Evidence Appendix 

None. 



Related Proceedings Appendix 

None. 



